-
Notifications
You must be signed in to change notification settings - Fork 586
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: remove GetHeight from ClientMessage interface #1285
chore: remove GetHeight from ClientMessage interface #1285
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! My only concern is around handling duplicate updates. Probably best to just decide on our ideal solution and then see how it breaks relayers (and then revert if necessary)
ctx.EventManager().EmitEvents(sdk.Events{ | ||
sdk.NewEvent( | ||
types.EventTypeUpdateClient, | ||
sdk.NewAttribute(types.AttributeKeyClientID, clientID), | ||
sdk.NewAttribute(types.AttributeKeyClientType, clientType), | ||
sdk.NewAttribute(types.AttributeKeyConsensusHeight, consensusHeight.String()), | ||
sdk.NewAttribute(types.AttributeKeyConsensusHeight, consensusHeights[0].String()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, I think we need a len(consensusHeights) > 0 check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was being checked in the UpdateClient()
method of keeper.go.
if len(consensusHeights) != 0 {
// emit events, otherwise no-op & return nil
}
return nil
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yes. The only strange part is that this function assumes you pass in a non empty array of consensus heights
Unrelated, could we add // deprecated
next to the consensus height
attribute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we backport consensusHeights
attribute to older releases? That way relayers could switch to it without waiting for all chains to upgrade to this version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only strange part is that this function assumes you pass in a non empty array of consensus heights
Agree, it is kind of strange. I'll adapt to check len(consensusHeights)
inside event emission func and remove the check from the UpdateClient
keeper method.
Should we backport consensusHeights attribute to older releases?
Sounds like a good idea, but this would require a separate PR to main, correct?
Edit: I'll also add deprecated comment in-line 👍 Now that I'm looking at this once again, AttributeKeyConsensusHeight
is used for create and upgrade events as a single height value, and should probably be maintained. In which case, I think the deprecation notice should only be here, solely for the update events and not in types/events.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch!
|
||
k.Logger(ctx).Info("client state updated", "client-id", clientID, "height", consensusHeight.String()) | ||
if len(consensusHeights) != 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think not emitting UpdateClientEvent
on a successful MsgUpdateClient
is problematic. I may be wrong though. Would be good to check with relayers what the best expected functionality is for dup updates
The main odd thing is if you query for UpdateClient events, this message wouldn't come up. To me, it'd make more sense if the event was emitted, but indicated it was a duplicate update
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to change this to return the height from the ClientState
implementation on duplicate updates.
However, I don't think we can provide information about duplicate updates in the events, that would only be possible if emitting from 07-tendermint
for example, but as we discussed before they should be emitted from 02-client
in a somewhat standardised fashion.
If we're in agreement, I can update this PR to return the height on duplicates and also make the changes to remove the error
return value and panic instead.
Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking if consensus_heights
is empty, we should just return "" in the consensus heights attribute. Thoughts?
In favor of removing error
return 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated and removed the error return, and also returning the height on duplicate header updates from 07!
…ing GetHeight from solomachine Header, updating tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I still have some reservations about not emitting events for successful MsgUpdateClient
which the light client does not return consensus heights for. Naturally, it makes more sense to me to emit event which indicates that result (since otherwise if you query via events, this message cannot be retrieved).
ctx.EventManager().EmitEvents(sdk.Events{ | ||
sdk.NewEvent( | ||
types.EventTypeUpdateClient, | ||
sdk.NewAttribute(types.AttributeKeyClientID, clientID), | ||
sdk.NewAttribute(types.AttributeKeyClientType, clientType), | ||
sdk.NewAttribute(types.AttributeKeyConsensusHeight, consensusHeight.String()), | ||
sdk.NewAttribute(types.AttributeKeyConsensusHeight, consensusHeights[0].String()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yes. The only strange part is that this function assumes you pass in a non empty array of consensus heights
Unrelated, could we add // deprecated
next to the consensus height
attribute
ctx.EventManager().EmitEvents(sdk.Events{ | ||
sdk.NewEvent( | ||
types.EventTypeUpdateClient, | ||
sdk.NewAttribute(types.AttributeKeyClientID, clientID), | ||
sdk.NewAttribute(types.AttributeKeyClientType, clientType), | ||
sdk.NewAttribute(types.AttributeKeyConsensusHeight, consensusHeight.String()), | ||
sdk.NewAttribute(types.AttributeKeyConsensusHeight, consensusHeights[0].String()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we backport consensusHeights
attribute to older releases? That way relayers could switch to it without waiting for all chains to upgrade to this version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent! Thanks for following up on my suggestion. I think the previous solution was a great one, but I think this makes more sense given the history of how the SDK is used
Totally agree, I think we got to the best possible solution anyways! Thanks for the discussions and reviews 👍 |
* adding new consensus heights return value from UpdateState interface, updating 02-client events emission * removing GetHeight() from ClientMessage interface, updating tests * updating godocs to include returned consensus height data * removing unused event emission func, adding deprecation notice, removing GetHeight from solomachine Header, updating tests * removing error return from UpdateState, returning height on duplicate header update * updating event emissions as per suggestions
Description
GetHeight
interface method fromClientMessage
.[]exported.Height
from the newUpdateState
interface.len(consensusHeights)
to guard against index out of range errors on no-op updatesAttributeKeyConsensusHeights
and returning a comma separated list of consensus heightscloses: #594
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes